Pubsub dashboards guide #3091

splindsay-92 · 2026-01-12T09:45:19Z

Description

Checklist

Commits have been rebased.
Linting has been run against the changed file(s).
The PR adheres to the writing style guide and contribution guide.

…ocessing strategies.

…sistency and readability.

…mples for large audiences

coderabbitai · 2026-01-12T09:45:25Z

Important

Review skipped

Auto reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

paddybyers

@m-hulbert This text contains a lot of AI giveaways, such as em dashes, and emboldened bulleted lists. Does (or should) our style guide say we aim to avoid these?

paddybyers · 2026-01-12T10:54:17Z

src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx

+
+Ably applies rate limits to ensure platform stability. By default, channels accept up to 50 inbound messages per second. Enterprise plans can request higher limits for specific use cases. When working with high-frequency data sources, consider batching multiple updates into single messages to stay within these limits.
+
+For example, data sources generating more than 50 updates per second could be batched into periodic publishes:


Why are we suggesting doing this instead of server-side batching?

paddybyers · 2026-01-12T10:55:51Z

src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx

+
+The key benefit of server-side batching is that it reduces billable outbound message count, especially during traffic spikes. If your source publishes 10 updates per second and you have 1000 subscribers, without batching you'd have 10,000 outbound messages per second. With 500ms batching, messages are grouped into 2 batches per second, resulting in 2,000 outbound messages per second—a 5x reduction.
+
+Unlike message conflation, server-side batching preserves all messages and message order. Every update is delivered, just grouped together for efficiency. This makes it suitable for scenarios where you need complete data, but can tolerate some latency in exchange for cost savings.


There are some nuances about changes to message ordering - order is preserved for messages of a given type, but ordering of messages vs presence messages, or live objects updates, etc, can change.

paddybyers · 2026-01-12T10:57:36Z

src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx

+
+#### Pairing with persist last message
+
+For state-based dashboards using delta compression, the [persist last message](/docs/storage-history/storage#persist-last-message) channel rule provides a means to store and query the latest state on the channel. When enabled, Ably stores the most recent message published to a channel for 365 days. New clients can then attach with `rewind=1` to immediately receive the last published state, or query it via history.


Should we be clear on when we recommend this vs just persistence?

A dashboard is likely to be based on data that's consistently updated, so persist-last doesn't feel like the right solution.

m-hulbert · 2026-01-12T12:39:02Z

@m-hulbert This text contains a lot of AI giveaways, such as em dashes, and emboldened bulleted lists. Does (or should) our style guide say we aim to avoid these?

@paddybyers it doesn't currently, but I have a doc that updates the contributing guide to an MDX focus so I'll include an update to the style guide with that. It's a good shout.

m-hulbert

Thanks Steven. Added some comments throughout;

I agree with Paddy's comment about common AI'isms.
I think we should have some placeholders for images in here.
Is it worth mentioning charts as well as dashboards (will be good for images, and its likely the same data in most, if not all cases).
In the opening sections we talk about critical vs fan engagement as the 2 types of dashboard throughout, but then some sections don't mention this again and refer to different types.

m-hulbert · 2026-01-16T08:59:07Z

src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx

+
+The most important decision you can make when developing a realtime dashboard is understanding the experience you want users to have and the criticality of the data being delivered. This will determine the architecture, feature set, and ultimately the impression your users leave with.
+
+The key architectural decision is understanding which category your dashboard falls into. With Ably, you are not limited by technology—only by the user experience you want to deliver. Realtime dashboards typically fall into two categories, each with distinct requirements:


I think the spacing is off here technology-only vs technology - only (or better yet technology, only)

m-hulbert · 2026-01-16T09:01:14Z

src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx

+
+For healthcare applications, Ably is HIPAA-compliant and offers Business Associate Agreements (BAAs) for customers handling Protected Health Information (PHI).
+
+Understanding which category your dashboard falls into—or whether it combines elements of both—is fundamental to making the right architectural decisions throughout this guide.


Should this be in the opening section rather than underneath one of the options?

m-hulbert · 2026-01-16T09:12:16Z

src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx

+```
+</Code>
+
+The single channel pattern maximizes cost efficiency because Ably's fanout delivers each published message to all subscribers with a single outbound message charge per subscriber. There's no duplication of data across channels, and the architecture remains simple to reason about.


"simple to reason about"?

m-hulbert · 2026-01-16T09:17:52Z

src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx

+
+For dashboards where only the current state over some time window matters—stock prices, sensor readings, vehicle positions—[message conflation](/docs/messages#conflation) delivers only the most recent value within each time window.
+
+Configure conflation through [rules](/docs/channels#rules) in your dashboard. You'll specify a conflation interval and a conflation key pattern that determines which messages are considered related. Messages with the same conflation key within the time window are conflated together, with only the latest delivered. Multiple conflated messages are then delivered in a single batch at the end of the interval.


We aren't offering an equivalent paragraph for SSB as this one. We should either include for both, or assume the link to config instructions is sufficient IMO.

m-hulbert · 2026-01-16T09:19:35Z

src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx

+
+Conflation dramatically reduces costs when publishers send updates faster than users can perceive. If a price feed publishes 10 updates per second but your dashboard refreshes only each second, you're wasting 90% of your message budget on updates users never see. With 100ms conflation, you reduce outbound messages by 10x while showing users the most current data available.
+
+### Configuring rules


I think this may be redundant given my previous comment. A brief overview of each about the interval and conflationKey etc. with a link to their relevant docs is probably enough rather than a whole section in here describing how to use the dashboard.

m-hulbert · 2026-01-16T09:39:13Z

src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx

+```
+</Code>
+
+Presence is powerful but expensive at scale. Every enter, leave, and update event generates messages delivered to all presence subscribers. For a channel with 1000 viewers all subscribed to presence, a single user joining triggers 1000 outbound messages. If users are frequently joining and leaving, this can quickly dominate your message costs.


I think it's odd to mention this dominating your message costs and then the section about handling it in a more cost-efficient manner is 2 sections below.

m-hulbert · 2026-01-16T09:40:17Z

src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx

+
+[Server-side batching](/docs/messages/batch#server-side) groups messages before fanout, dramatically reducing outbound message count during high-activity periods. This is particularly valuable when your data source publishes multiple updates per second.
+
+To understand the impact, consider a live sports dashboard with 100,000 viewers and a data source publishing 10 updates per second during an exciting match:


Would you be sending this high frequency of data in a sports dashboard? 🤔

m-hulbert · 2026-01-16T10:04:18Z

src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx

+```
+</Code>
+
+When a client disconnects abruptly without calling close(), Ably maintains the connection state for 2 minutes to enable reconnection. Calling close() explicitly releases resources immediately.


Suggested change

When a client disconnects abruptly without calling close(), Ably maintains the connection state for 2 minutes to enable reconnection. Calling close() explicitly releases resources immediately.

When a client disconnects abruptly without calling `close()`, Ably maintains the connection state for 2 minutes to enable reconnection. Calling `close()` explicitly releases resources immediately.

m-hulbert · 2026-01-16T10:06:14Z

src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx

+
+If you're using [message conflation](#message-conflation-for-latest-value-scenarios) to optimize dashboard delivery costs, be aware that conflated messages are also what gets streamed to external systems. If you need complete data for analytics or audit purposes but want conflation for dashboard delivery, you may have to consider other publish patterns.
+
+### Message format considerations


I think this is worth noting, but we don't need to go into all this detail / have a specific section for it.

m-hulbert · 2026-01-16T10:07:33Z

src/pages/docs/guides/pub-sub/dashboards-and-visualizations.mdx

+
+Non-enveloped messages deliver just the raw payload, which is useful when your downstream system expects a specific format or you want to minimize data transfer. However, you'll lose the channel and metadata context that enveloped messages provide.
+
+## Production-ready checklist


This and the following 2 sections are a lot of bullet points which I'm not convinced are all helpful. A lot of the next steps links are already linked throughout the guide too.

splindsay-92 added 16 commits January 9, 2026 14:01

add health tech guide

5bbc3f7

add health tech guide

f80d483

wip

7d490fa

wip

1658f9d

wip

b52d46e

wip

5d26e6b

wip

cb60cd5

wip

2e844b1

refactor some text blocks to include lists/bullets

37680a2

update health tech guide with channel rules and optimization strategies

9d12abf

rename health tech dashboard guide to dashboards and visualizations

359f5d7

updated recommendations on channel rules, optimizations, and batch pr…

0141f99

…ocessing strategies.

refactor code examples in dashboards and visualizations guide for con…

338b528

…sistency and readability.

update scaling presence section with detailed recommendations and exa…

7ffd056

…mples for large audiences

simplify streaming for audit and analytics section.

79f932a

reorganize streaming for audit and analytics section

ef4c4f2

paddybyers reviewed Jan 12, 2026

View reviewed changes

m-hulbert reviewed Jan 16, 2026

View reviewed changes


		Ably applies rate limits to ensure platform stability. By default, channels accept up to 50 inbound messages per second. Enterprise plans can request higher limits for specific use cases. When working with high-frequency data sources, consider batching multiple updates into single messages to stay within these limits.

		For example, data sources generating more than 50 updates per second could be batched into periodic publishes:


		The key benefit of server-side batching is that it reduces billable outbound message count, especially during traffic spikes. If your source publishes 10 updates per second and you have 1000 subscribers, without batching you'd have 10,000 outbound messages per second. With 500ms batching, messages are grouped into 2 batches per second, resulting in 2,000 outbound messages per second—a 5x reduction.

		Unlike message conflation, server-side batching preserves all messages and message order. Every update is delivered, just grouped together for efficiency. This makes it suitable for scenarios where you need complete data, but can tolerate some latency in exchange for cost savings.


		#### Pairing with persist last message

		For state-based dashboards using delta compression, the [persist last message](/docs/storage-history/storage#persist-last-message) channel rule provides a means to store and query the latest state on the channel. When enabled, Ably stores the most recent message published to a channel for 365 days. New clients can then attach with `rewind=1` to immediately receive the last published state, or query it via history.


		The most important decision you can make when developing a realtime dashboard is understanding the experience you want users to have and the criticality of the data being delivered. This will determine the architecture, feature set, and ultimately the impression your users leave with.

		The key architectural decision is understanding which category your dashboard falls into. With Ably, you are not limited by technology—only by the user experience you want to deliver. Realtime dashboards typically fall into two categories, each with distinct requirements:


		For healthcare applications, Ably is HIPAA-compliant and offers Business Associate Agreements (BAAs) for customers handling Protected Health Information (PHI).

		Understanding which category your dashboard falls into—or whether it combines elements of both—is fundamental to making the right architectural decisions throughout this guide.


		For dashboards where only the current state over some time window matters—stock prices, sensor readings, vehicle positions—[message conflation](/docs/messages#conflation) delivers only the most recent value within each time window.

		Configure conflation through [rules](/docs/channels#rules) in your dashboard. You'll specify a conflation interval and a conflation key pattern that determines which messages are considered related. Messages with the same conflation key within the time window are conflated together, with only the latest delivered. Multiple conflated messages are then delivered in a single batch at the end of the interval.


		Conflation dramatically reduces costs when publishers send updates faster than users can perceive. If a price feed publishes 10 updates per second but your dashboard refreshes only each second, you're wasting 90% of your message budget on updates users never see. With 100ms conflation, you reduce outbound messages by 10x while showing users the most current data available.

		### Configuring rules


		[Server-side batching](/docs/messages/batch#server-side) groups messages before fanout, dramatically reducing outbound message count during high-activity periods. This is particularly valuable when your data source publishes multiple updates per second.

		To understand the impact, consider a live sports dashboard with 100,000 viewers and a data source publishing 10 updates per second during an exciting match:

	When a client disconnects abruptly without calling close(), Ably maintains the connection state for 2 minutes to enable reconnection. Calling close() explicitly releases resources immediately.
	When a client disconnects abruptly without calling `close()`, Ably maintains the connection state for 2 minutes to enable reconnection. Calling `close()` explicitly releases resources immediately.


		If you're using [message conflation](#message-conflation-for-latest-value-scenarios) to optimize dashboard delivery costs, be aware that conflated messages are also what gets streamed to external systems. If you need complete data for analytics or audit purposes but want conflation for dashboard delivery, you may have to consider other publish patterns.

		### Message format considerations


		Non-enveloped messages deliver just the raw payload, which is useful when your downstream system expects a specific format or you want to minimize data transfer. However, you'll lose the channel and metadata context that enveloped messages provide.

		## Production-ready checklist

Pubsub dashboards guide #3091

Are you sure you want to change the base?

Pubsub dashboards guide #3091

Conversation

splindsay-92 commented Jan 12, 2026

Description

Checklist

Uh oh!

coderabbitai bot commented Jan 12, 2026

Review skipped

Uh oh!

paddybyers left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

m-hulbert commented Jan 12, 2026

Uh oh!

m-hulbert left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants